% Dokumentation App-Projekt (6.FS)

\documentclass[titlepage]{article}

\title{
\large{Universit\"at Potsdam - WiSe 2011/2012} \\ \vspace*{30mm}
\huge{\textbf{Matching Game}}\\ \vspace*{5mm}
\Large{Dokumentation des agilen Prozesses\\ bei der Entwicklung einer Android Lern-App\\} \vspace*{5mm}
\large{betreuender Dozent: Dr. Ralf Romeike}\\ \vspace*{15mm}
%\rule{0.8\textwidth}{0.1pt}
}

\author{Eric Tabbert \\
		Matrikelnummer: 743405 \\ 
		Computerlinguistik (B.Sc.) \\ 
		7. Fachsemester \\
		\and
		Anne Schumacher\\ 
		Matrikelnummer: 745166 \\ 
		Computerlinguistik (B.Sc.) \\ 
		6. Fachsemester \\	
}
\date{}

\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc} % Codierung (Umlaute, Klammern etc)
\usepackage[T1]{fontenc}	% verbessert Silbentrennung bei Wörtern mit Umlaugen
\usepackage{graphicx}		% Grafiken einbinden
\usepackage{enumerate}		% Aufzählungen flexibler gestalten
\usepackage[margin=10pt,	% Schönere Bildbeschriftung
font=small,labelfont=bf,labelsep=endash]{caption}
\usepackage{booktabs}		% schönere Tabellen
\usepackage[round,authoryear]{natbib} % für Zitierstyle



\begin{document}

\maketitle
\setcounter{page}{7}
\newpage

\section{Einleitung}
Im Rahmen des Kurses \textit{Entwicklung mobiler (Lern-) Apps mit Android Smartphones und Tablets} haben wir eine Andoid Application für Vorschulkinder implementiert. Dabei bemühten wir uns,  die im Kurs erlernten agilen Methoden der Software-Entwicklung anzuweden und zu reflektieren. 

Die Aufgabe war es, eine Lern-App zur Förderung kognitiver Stützfunktionen bei Kindern zu realisieren. Das konkrete Design der App stammte dabei von Studenten, die sich mit frühkindlicher Bildung beschäftigen. In userer App sollte es darum gehen, Bilder zu vergleichen und hinzugefügte oder veränderte Objekte zu finden, was insgesamt zur Föderung der Konzentration des Anwenders beitragen soll.


\section{Projektplanung}
Bevor wir mit der Entwicklung der Lern-App begannen, haben wir uns zunächst zusammengesetzt und den Ablauf geplant. Zunächst führten wir ein Brainstorming durch, welches uns grob aufzeigte, was es überhaupt zu tun gab. Daraus hervorgehend haben wir uns folgende Userstories überlegt:

\begin{itemize}\itemsep0pt
\item Layout mit vertikaler Trennung ist vorhanden.
\item Schwierigkeitsstufe 1 funktioniert.
\item Schwierigkeitsstufe 2 funktioniert.
\item ein Fortschrittsbalken existiert.
\item Soundeffekte sind vorhanden.
\item Es gibt ein Zeitlimit für die Bearbeitung von Teilaufgaben.
\end{itemize}
Da wir jedoch keinen Kontakt zum Kunden aufnehmen konnten (siehe Abschnitt \ref{sec:problems}), war es für uns eher schwierig einzuschätzen, wie realistisch und relevant diese User Stories sein würden. Aufbauend auf den Stories, haben wir Tasks entwickelt. Geplant war, dass wir uns einmal pro Woche für die Entwicklung der Lern-App treffen. Vom Zeitpunkt der Aufgabenstellung bis zur Abgabe blieb uns ein Zeitfenster von sieben Wochen. Unsere Tasks richteten wir so ein, dass ein Task den Zeitumfang von einer Woche (also einer Sitzung) nicht überschreiten sollte. Die einzelnen Tasks und die idealen Zeitpunkte ihrer Fertigstellung können in Tabelle \ref{table:tasks} eingesehen werden.

\begin{table}[h]
\caption{Taskplanung}
\centering
\begin{tabular}{c l c}
\toprule
Tasknr. & Taskinhalt & abgeschl. in Woche \\
\midrule
1 & Hello-World-App programmieren & 1\\
2 & Layout entwerfen & 2\\
3 & versteckte Suchfelder einfügen & 3\\
4 & Datenstrukturen \& Klassen entwerfen & 4\\
5 & Funktionen schreiben & 5\\
6 & Debuggen & 6\\
7 & Progress bar einfügen & 7\\
8 & Soundeffekte einfügen & 7\\
\bottomrule
\end{tabular}
\label{table:tasks}
\end{table}

Des weiteren haben wir uns drei Meilensteine gesetzt, welche die Zwischenziele unseres Projektes verdeutlichen sollten:
\begin{itemize}\itemsep0pt
\item Woche 2: UI-Layout steht
\item Woche 4: Datenstrukturen sind ausgearbeitet
\item Woche 7: Prototyp der App läuft
\end{itemize}


\section{Programmstruktur}
\begin{figure}[h]
\centering
\fbox{\includegraphics[height=10cm]{screenshot}}
\caption{GUI-Screenshot des Matching Games}
\label{fig:screenshot}
\end{figure}


Der Java-Code unseres Projektes besteht bis jetzt aus vier Klassen, ebenso vielen Layout-XML-Dateien, sowie einigen weiteren Abhängigkeiten (die zu vergleichenden Bilder und die Leveldaten-Datei). Die Organisation des Projektes lässt sich funktional in zwei Bereiche untergliedern: einerseits die Architektur für das Verwalten der Spielelevel - die Klassen \textit{PicInfoStorage (PIS)}, \textit{Level} und \textit{LevelsContainer} - und andererseits die eigentliche Spiellogik in der \textit{MatchingGameActivity}-Klasse.

Von den Spielelevel-Klassen ist die \textit{PicInfoStorage}-Klasse die atomarste. Sie speichert die Pfade für die Bilder und die Koordinaten an denen bei diesen Bildern die Modifikationen vorgenommen wurden. Damit repräsentiert sie die kleinste Informationseinheit eines Levels, die man auch als \textit{Layer} bezeichnen könnte. Für diese nur durch die Basisdatentypen int und string vertretenen Informationen stellt sie die üblichen getter- und setter-Funktionen zum Auslesen und Befüllen der Instanzvariablen zur Verfügung. Als ungewöhnlich ist vielleicht zu erwähnen, dass alle Informationen über dieselbe \textit{addinfo()}-Funktion hinzugefügt werden, welche anhand einer Kontrollvariable feststellt, welche Informationen bereits eingefügt wurden und welche demnach als nächstes zu befüllen ist. Diese Designentscheidung wird für das spätere Einlesen der Daten einen positiven Effekt haben.

Die \textit{Level}-Klasse fasst nun mehrere dieser \textit{PIS}-Elemente oder Layer zu einem Level zusammen. Neben der Datenstruktur, die die Layer speichert (bei uns durch eine Java-typische ArrayList realisiert), enthält die Klasse zwei Kontrollvariablen, die den Schwierigkeitsgrad des Levels und den zuletzt abgerufenen Layer speichern. 
Der Schwierigkeitsgrad des Levels wird durch eine Funktion kontrolliert, die beim initialen Befüllen des Levels die Layer daraufhin überprüft, ob sie zwei Koordinatenpaare enthält - also Platzierungsinformationen für zwei statt nur einem Button. Sobald ein Layer hinzugefügt wird, der zwei Koordinatenpaare enthält, wird die Schwierigkeitsstufe auf 2 gesetzt. Für die Überprüfung stellt die \textit{PIS}-Klasse eine entsprechende Funktion zur Verfügung. Außerdem implementiert die Klasse unter anderem getter- und setter-Methoden für die Layer, Standardmethoden wie \textit{isEmpyt()} oder \textit{clear()}, sowie Iteratoren.

\hspace{20pt} Letztendlich kulminiert die Levelarchitektur in der \textit{LevelsContainer}-Klasse. Diese verknüpft nun wiederum die Level-Instanzen und stellt auch wieder die gängigen Zugiffs- und Verwaltungsmethoden bereit. Hinzu kommen Iteratoren für das Iterieren der einzelnen Level des Spiels.
Die LevelsConatainer-Klasse ist aber auch der Ort, der die Funktionalität für das Einlesen der Leveldaten aus der Leveldatendatei (eine übliche \textit{comma seperated values (CSV)}-Textdatei bereitstellt. Das macht Sinn, da die Datendatei immer die Informationen für alle Level des Spiels enthält und nur diese Klasse den Handlungsskopus über mehrere Level und ihre Abhängigkeiten hat. Für das Einlesen wird jede Zeile einzeln gelesen, tokenisiert und zu einem neuen Layer gemacht. Das erzeugen der Layer kann ganz einfach über eine while-Schleife funktionieren, da die vorhin angesprochene \textit{addInfo()}-Funktion sich um die genaue Zuordnung von Inhalt und korrekter Variable kümmert. Die einzelnen Layer werden dann zu Leveln kumuliert und diese wiederum im Klassenobjekt abgespeichert.

Die Logik des Spiels liegt in der Klasse \textit{MatchingGameActivity}. Diese Klasse bringt alles zusammen: Die Bilder, die Buttons, die Leveldaten und die verschiedenen Layouts. Das Spiel beginnt, sobald der Startbutton auf dem Startlayout gedrückt wird. Dann werden einmalig die Leveldaten geladen. Mit diesen wird der erste Layer des ersten Levels in eines des beiden Spiel-Layouts geladen. Die Spiel-Layouts sind XML-Dateien, die die zwei Bilder nebeneinander platzieren (nach unserer Vorgabe das modifizierte Bild immer rechts). Je nach Level werden ein oder zwei versteckte Buttons in das Layout geladen. Wird einer der Buttons gedrückt, wird überprüft ob der andere Button ggf. schon gefunden wurde und je nachdem eine Erfolgsnachricht ausgegeben, der nächste Layer oder das nächste Level geladen. Wurden alle Levels absolviert, gelangt man auf einen Gratulations-Bildschirm. Von dort, ebenso wie von dem Button der immer unter den Bildern angezeigt wird, kommt man zurück zum Startbildschirm.



\section{Umsetzung der Lern-App}
Für die Umsetzung des Projektes waren wir uns anfangs nicht ganz sicher, ob wir die für uns großen Neuerungen mit IDE, Java, Android SDK, GUI-Programmierung und Spiele-Programmierung tatsächlich alle gleich mit Eclipse angehen sollten. Nachdem wir uns aber die \textit{AppInventor}-Einführung von unserem Dozenten angehört und uns noch selber dazu informiert hatten, wollten wir es aber wenigstens mit Eclipse versuchen. Die Hauptgründe waren der beschränkte Funktionsumfang und die schon vorab bekannte zeitliche Einschränkung von AppInventor.

Beim Programmieren selbst haben wir uns stets bemüht, die agilen Methoden einfließen zu lassen, die wir im Kurs behandelt haben. Das Programmieren haben wir immer in Pairprogramming durchgeführt. Obwohl das anfangs sehr ungewohnt war, haben wir vor allem gemerkt, dass dadurch viele Schusselfehler vermieden werden. Auch das ständige Erklären des eigenen Vorgehens war etwas umständlich, hatte aber wiederum den Vorteil, dass undurchdachte Vorablösungen wesentlich geringere Chancen hatten ihren Weg in das Programm zu finden. Ein weiterer Vorteil des Pairprogrammings war, dass der Partner bei einer der vielen Fragen zu IDE, Java oder Android SDK (siehe Abschnitt \ref{sec:problems}) verhältnismäßig schnell nachsehen konnte, während man selbst versuchte das Problem eigenständig in den Griff zu bekommen (z.B. unaktuelle, automatisch-erstellte R.Java).

Da wir beide zumindest schon Erfahrung in der Programmierung mit C++ hatten, war uns das \textit{Don't Repeat Yourself (DRY)}-Prinzip schon vertraut (wenn auch nicht vom Namen), sodass uns dessen Beachtung wenig Aufmerksamkeit abverlangte. Dasselbe gilt für das \textit{Single Responsibility Principle (SRP)}, dessen Beachtung allerdings nicht ganz so unbewusst von der Hand ging, vor allem deswegen, weil die Dopplung von Funktionalität vorwiegend in verschiedenen Klassen auftrat und auch nicht immer sofort ersichtlich war, dass zwei Funktionen (oder zwei Cluster von Funktionen... ) letztlich doch denselben Zweck erfüllen.

Am schwierigsten fiel uns letztendlich jedoch der Vorsatz des \textit{Good-enough-design}. Wir beide haben eine Tendenz dazu, wenn wir an einer Stelle im Code anfangen, von einer Funktion zur nächsten und somit vom hundertsten ins tausendste zu arbeiten. Dieses starke Vorausarbeiten an einer Stelle führte aber trotz allen Planens (oder gerade deswegen...) häufig dazu, dass wir später nochmal Änderungen vornehmen mussten, weil eine andere Stelle im Code doch nicht so möglich oder optimal war, wir es eigentlich gedacht hatten. Wir haben uns deshalb selbst dazu gezwungen, stets nur das zu machen, was höchste Priorität hat und erst dann weitere Abstraktion, Dynamität oder höheren Funktionalitätsumfang einzufügen.


\section{Reflektion}
\subsection{Einhaltung des Zeitplans}
Durch anfängliche Komplikationen, die vor allem technischer Natur waren (Probleme beim Einrichten von Eclipse und der Installation des Android SDKs), hat sich unser Zeitplan etwas nach hinten verschoben. Somit konnte leider nur einer der drei Meilensteine (die Fertigstellung eines lauffähigen Prototyps) zum vorgegebenen Zeitpunkt erreicht werden. In Grafik \ref{fig:burndown} ist unsere Burn-Down-Chart zu sehen, in der wir den Ablauf der idealen und der realen Taskerfüllung dokumentiert haben.

\begin{figure}[ht]
\centering
\includegraphics[width=10cm]{burndown}
\caption{Burn-Down-Chart}
\label{fig:burndown}
\end{figure}
Wie bereits erwähnt, kam die anfängliche Verzögerung durch technische Probleme zustande. Für die Einrichtung der Entwicklungsumgebung und das Vertrautmachen mit der Software und der Programmiersprache hätten wir mehr Zeit einplanen müssen. Dafür haben wir uns sehr schnell in die xml-basierte Erstellung des Layouts eingearbeitet und konnten somit Task 2 und 3 innerhalb einer statt geplanter zwei Wochen abschließen. Für den Entwurf der Datenstrukturen und das Software-Design haben wir jedoch mehr Zeit benötigt als zunächst veranschlagt. Weiterhin war es schwierig Task 4 und 5 strikt voneinander zu trennen, da das Klassendesign und die Funktionalitäten stark voneinander abhängen. Insgesamt haben wir für Task 3-5 (Klassenstrukturen entwerfen, Funktionen schreiben, Debuggen) vier statt nur drei Wochen gebraucht. Für die beiden übrigen Tasks (Progressbar und Soundeffekte einfügen) blieb am Ende leider nicht mehr genügend Zeit.

Die User Stories konnten weitgehend erfüllt werden, abgesehen von den Soundeffekten und dem Zeitlimit. Letzteres hatten wir jedoch auch nicht in unsere Tasks integriert, da wir dies zunächst für nicht allzu wichtig befanden.

\subsection{Schwierigkeiten} \label{sec:problems}
Probleme, die wir während der Entwicklungsphase hatten, lassen sich größtenteils auf unsere Unerfahrenheit bezüglich der Software-Entwicklung zurückführen. Im Rahmen dieses Projektes sind wir mit vielen Dingen zum ersten Mal überhaupt in Kontakt gekommen. Darunter z.B. die Erstellung eines eigenen graphischen User Interfaces (GUI), die Entwicklung eines Spiels oder die aktive Nutzung einer IDE (Eclipse) Auch hatten wir weder Vorkenntnisse in der Java-Programmierung, noch schonmal Software für mobile Endgeräte geschrieben. Sodass die dringend erforderlcieh Vertrautheit mit dem Android SDK nicht vorhanden war, weswegen wir viel Zeit für das Erlernen dieser Standbeine einkalkulieren mussten. Durch die eher lange Eingewöhnungsphase ist uns letzten Endes dann leider wertvolle Zeit für die eigentliche Entwicklung der Software verloren gegangen.

Schwierig war auch das fehlende Kunden-Feedback, welches bei der Entwicklung eines in Auftrag gegebenen Produktes unabdingbar ist. Konzepte wie die User Stories und Meilensteine, die im agilen Prozess gemeinsam mit dem Kunden hätten entworfen und diskutiert werden sollen, haben somit an Relevanz verloren. Außerdem war es daher nicht möglich uns mehr Klarheit über die Wünsche und Spezifikationen des Kunden zu verschaffen. Dass wir anstatt auf Antwort vom Kunden zu warten stattdessen unseren betreuenden Dozenten hätten konsultieren können, war uns während der Entwicklung nicht klar.


\subsection{Offene Tasks}
Nach Fertigstellung des Prototypen sind noch einige Punkte offen geblieben, die bei einer Vervollständigung der Lern-App noch bearbeitet werden sollten.

Dazu gehört natürlich die Behebung der Fehler, die beim bisherigen Bugfixing noch nicht beseitigt werden konnten. Beim aktuellen Stand des Prototypen werden die Felder, die zur Aktivierung des nächsten Levels gefunden werden müssen, noch nicht korrekt positioniert.

Der Prototyp ist noch nicht dafür ausgelegt, dass er auf verschiedenen Endgeräten einwandfrei funktioniert. Probleme können bei der Positionierung der Suchfelder bei unterschiedlichen Bildschirmauflösungen auftreten. Dies liegt daran, dass die Felderpositionen momentan noch absolut anstatt relativ angegeben sind. Dieses Provisorium sollte bei der Weiterverfolgung des Projektes also möglichst eine hohe Priorität erhalten.

Die Fortschrittsbalken (einer für den Level-Fortschritt und ein weiterer für den gesamten Spielfortschritt) müssen noch ihre Funktionalität erhalten. Im Prototypen sind beide Balken schon vorhanden und manuell ansprechbar, jedoch git es Bugs beim automatischen Aktualisieren. Auch Soundeffekte sollten noch eingefügt werden, z.B. als Bestätigung wenn ein Level oder Sublevel abgeschlossen wird. Ein Zeitlimit für die einzelnen Sublevels könnte - je nach Kundenwunsch - ebenfalls noch eingefügt werden.

Das Layout und die Menü-Navigation müsste ebenfalls noch ein wenig nachgebessert werden, da sie noch nicht den Vorgaben entsprechen, sondern bis dato nur vorbereitet sind. Damit sie den Vorgaben entsprechend gestaltet werden können, müsste der Kunde jedoch noch Grafiken und konkretere Spezifikationen liefern.

In denjenigen Leveln, in denen zwei Objekte gefunden werden müssen, erscheint im Prototypen nach dem Antippen des ersten Objektes ein schriftlicher Hinweis, dass noch ein weiteres gefunden werden muss. Da das Lesen eines Textfeldes selbstverständlich nicht den Fähigkeiten eines Vorschulkindes entspricht, muss dieser Hinweis noch entsprechend angepasst werden. Besser wäre es z.B. eine grau-hinterlegte Grafik am Bildschirmrand einzufügen, die beim Antippen des ersten Suchobjektes zur Hälte farbig wird. Somit sollte dem Spieler bewusst werden, dass die Aufgabe teilweise, jedoch noch nicht vollständig erfüllt wurde.


\section{Resultat}
Zusammenfassend können wir sagen, dass wir mit diesem Projekt viel Neuland betreten haben und dadurch auch einen großen Wissenszuwachs hatten. Für zukünftige Projekte sollten wir definitiv (mehr) Zeit für das Einarbeiten in Programmierumgebungen bzw. generell andere Programmierumstände als die gewohnten einplanen.

Insgesamt haben uns die angewendeten agilen Methoden, obwohl sie etwas Eingewöhnung benötigt haben, gut geholfen und wir konnten sie erfolgreich einbringen. Insbesondere das \textit{Good-enough-Design} und womöglich auch das Pairprogramming sind Methoden, die wir für weitere Projekte anwenden wollen.

%Literaturverzeichnis:
%\newpage
%\nocite{*}
%\bibliographystyle{plainnat}
%\bibliography{literatur}


\end{document}